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CHAPTER  1 

GENERAL  DESCRIPTION 


1-1.  PURPOSE  OF  THE  USER'S  GUIDE.  The  purpose  of  this  user's  guide  is  to 
provide  personnel  with  the  information  necessary  to  effectively  utilize  the 
Extended  Parts  Requirements  and  Cost  Model  (Extended  PARCOM).  Extended 
PARCOM  is  a  planning  support  system  for  the  logistics  analyst/planner  which 
permits  the  examination  of  three  critical  logistics  issues: 

•  The  shortfall  of  current  fleet  combat  capability  relative  to  required 
capability  based  on  a  specified  current  spares  inventory. 

•  The  "best"  spares  mix  and  associated  fleet  combat  capability  achievable 
with  a  limited  amount  of  funds  for  add-on  spares. 

•  The  spares  cost  required  to  sustain  a  fleet  flying  program  for  a  speci¬ 
fied  number  of  days  and,  conversely,  the  number  of  days  of  such  sustain 
ability  achievable  with  a  specified  spares  "budget." 

1-2.  PROJECT  REFERENCES 

a.  Aircraft  Spares  Stockage  Methodology  (Aircraft  Spares)  Study, 
CAA-SR-84-12,  US  Army  Concepts  Analysis  Agency,  April  1984. 

b.  Overview/PARCOM  Turnkey  Project  (OPTP),  CAA-SR-84-33,  US  Army  Concepts 
Analysis  Agency,  November  1984. 

c.  Parts  Requirements  and  Cost  Model  (PARCOM)  User's  Guide,  CAA-D-84-10, 
US  Army  Concepts  Analysis  Agency,  October  1984. 

d.  Parts  Requirements  and  Cost  Model  (PARCOM)  Functional  Description, 
CAA-D-84-15,  US  Army  Concepts  Analysis  Agency,  October  1984. 

e.  Partial  Substitution  and  other  Modifications  to  the  PARCOM  Model, 
CAA-TP-84-11,  US  Army  Concepts  Analysis  Agency,  November  1984. 

f.  Extended  Parts  Requirements  and  Cost  Model  (Extended  PARCOM) 

Functional  Description,  CAA-D-85-3,  US  Army  Concepts  Analysis  Agency,  March 
1985. 

g.  Pickard,  W.  C.,  Zellner,  P.  A.,  and  Bailey,  D.  R.,  DOD  Assimilation 
of  US  Air  Force  Methodologies  for  Relating  Logistics  Resources  to  Materiel 
Readiness,  Synergy,  Inc.,  August  1983. 
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h.  Maximizing  Daily  Helicopter  Flying  Hours  Study  (MAX  FLY  Study), 
CAA-SR-83-11,  US  Army  Concepts  Analysis  Agency,  August  1983  (SECRET). 

1-3.  DEVELOPMENT  BACKGROUND 

a.  Model  Origin.  The  US  Army  Concepts  Analysis  Agency  (CAA)  developed 
the  Parts  Requirements  and  Cost  Model  (PARCOM)  to  generate  cost  effective 
mixes  of  aircraft  spare  parts  and  to  assess  aircraft  fleet  performance  under 
specified  wartime  scenario  conditions.  Development  occurred  during  the 
course  of  the  Aircraft  Spare  Stockage  Methodology  (Aircraft  Spares)  Study 
(reference  l-2a,  above)  conducted  by  CAA.  That  study,  and  PARCOM  development, 
were  in  response  to  interest  shown  by  the  Deputy  Chief  of  Staff  for  Logistics 
(DCSLOG)  in  developing  a  methodology  (or  methodologies)  relating  aircraft 
spare  parts  stockage  levels  to  combat  readiness  and  flying  hour  capability. 

The  calculation  of  spare  parts  requirements  and  of  the  effects  of  budgeting 
changes  had  been  a  slow  and  cumbersome  peacetime  oriented  exercise.  The 
principal  criterion  for  spares  stockage  had  been  the  achievement  of  acceptable 
stockout,  or  fill  rate,  levels.  To  more  realistically  predict  wartime  spare 
parts  requirements,  and  to  better  justify  budget  requests  for  spare  parts 
procurement,  the  Army  needed  a  more  responsive  methodology  based  on  wartime 
flying  hour  expectations  and  system  readiness/availability  requirements. 

PARCOM  was  developed  to  meet  that  need. 

b.  Follow-on  Effort.  Results  reported  in  Aircraft  Spares  were  suffi¬ 
ciently  encouraging  to  warrant  a  follow-on  study,  designated  the 
Overview/PARCOM  Turnkey  Project  (OPTP)  (reference  l-2b,  above).  Included 
in  the  objectives  of  OPTP  were  the  following  actions  pertaining  to  PARCOM: 

(1)  Document  PARCOM,  as  developed  in  the  Aircraft  Spares  Study,  and 
deliver  it  to  the  US  Army  Aviation  Systems  Command  (USAVSCOM).  This  docu¬ 
mentation  consisted  of  a  User's  Guide  (reference  l-2c,  above)  and  a  Functional 
Description  (reference  l-2d,  above). 

(2)  Evaluate  and  report  on  the  potential  for  extending  the  capability 
of  PARCOM  to  include  partial-substitution  parts  replacement  policies  and 
any  other  features  deemed  desirable  but  lacking  in  the  model  (PARCOM)  devel¬ 
oped  for  Aircraft  Spares.  A  technical  paper  (reference  l-2e,  above)  reported 
on  the  model  extension.  The  extended  model  is  denoted  as  Extended  PARCOM; 
the  original  model,  as  developed  in  the  Aircraft  Spares  Study,  is  denoted 
simply  as  PARCOM  or  basic  PARCOM. 

1-4.  PURPOSE.  The  OPTP  Study  proposed  delivery  of  documentation  for  Extended 
PARCOM  in  the  form  of  revisions  to  the  User's  Guide  and  Functional  Description 
for  basic  PARCOM.  This  report  includes  the  revisions  to  the  PARCOM  User's 
Guide.  Another  report  (reference  l-2f,  above)  includes  the  revisions  to 
the  PARCOM  Functional  Description. 

1-5.  TERMS  AND  ABBREVIATIONS.  The  following  listing  provides  an  explanation 
of  any  terms  or  acronyms  subject  to  interpretation  by  the  reader: 
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aircraft 


avail 


full  sub 


authorized  stock  age  list 

availability 

retail  repair  time 

US  Army  Concepts  Analysis  Agency 

cumulative 

depot  recycle  time 

failure  rate 

fraction 

full  substitution  (part  replacement  policy) 


identification 

initial 


MAX  FLY 


inventory 

Maximization  of  Daily  Flying  Hours  (study) 


minimum 


no  sub 


PARCOM 


not  mission  capable 

not  mission  capable  supply 

no  substitution  (part  replacement  policy) 

not  repairable  this  station 

number 

national  stock  number 

order  and  ship  time 
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prescribed  load  list 

replacement 
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required 

requirement(s) 


req 
rqmt 

spare(s)  replacements  for  modular  components,  assemblies  and 

subassemblies  whose  removal,  in  their  entirety,  from  an 
aircraft  prevents  it  from  functioning.  Includes,  items 
commonly  known  as  spares,  spare  parts,  and  repair  parts 
that  fit  the  definition. 

stk  stock 

sub  substitution 


1-6.  SECURITY  AND  PRIVACY.  All  program  code  and  listings  are  UNCLASSIFIED 
and  require  no  special  security  considerations. 

a.  The  classification  of  output  reports  depends  on  the  specific  data 
base  used  and  the  type  and  labeling  of  generated  output.  All  example 
output  in  this  report  is  UNCLASSIFIED. 

b.  The  classification  of  input  files  is  also  a  function  of  the  data 
base  used  and  the  user's  method  labeling.  All  example  input  in  this  report 
is  UNCLASSIFIED. 
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SYSTEM  SUMARY 


2-1.  SYSTEM  APPLICATION 

a.  Requirements  Mode.  Extended  PARCOM  provides  information  to  logistics 
staff  officers  on  the  parts  amounts  and  costs  of  cost-effective  mixes  of 
aircraft  spare  parts  required  to  achieve  a  specified  flying  program  under 
various: 

•  Part  replacement  policies 

•  Cost  constraints 

•  Initial  inventory  conditions 

•  Aircraft  availability  constraints 

The  options  for  requirements  cases  are  summarized  in  Table  2-1.  A  row  of 
"X"  entries  denotes  the  simultaneous  assignment  of  conditions  defining  each 
general  case  for  a  specified  partial-substitution  policy. 


Table  2-1.  Key  Attributes  of  Requirements  Cases 


Flying 

hour 

Aircraft  availability 

Cost 

objective 

objective 

objective 

No 

Minimum 

Consecutive 

Maximum 

specified 

daily 

daily 

cumulative 

aircraft 

aircraft 

Unconstrained 

Constrained 

achieved 

achieved 

avail- 

avail- 

funds 

funds 

ability 

ability 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

(1)  Parts  Replacement  Policy.  Whether  or  not  a  failed  critical  part 
degrades  aircraft  flying  hour  productivity  depends  on  the  parts  replacement 
policy  used.  Basic  PARCOM  represented  the  effects  of  only  two  specific 
policies,  full  substitution  and  no  substitution.  These  policies  are  special 
cases  of  the  partial-substitution  policy  capability  of  Extended  PARCOM. 


(a)  Full  and  No  Substitution.  Under  a  "no  substitution"  policy, 
only  a  spare  may  replace  a  failed  part.  Under  a  "full  substitution"  policy 

a  failed  part  may  be  replaced  by  either  a  spare  or,  if  a  spare  is  not  readily 
available,  by  a  serviceable  part  removed  from  an  aircraft  which  is  already 
NMC  (not  mission  capable).  A  third  parts  replacement  policy  is  "NMCS  =  0," 
which  has,  as  a  goal,  the  replacement  of  ^1J_  failed  parts  with  spares. 

Basically  the  "NMCS  =  0"  policy  is  just  a  "no  substitution"  policy  with  an 
additional  requirement  that  daily  aircraft  availability  be  1.00.  This  varia¬ 
tion  is  of  interest  since  it  represents  the  most  expensive  plausible  policy. 

In  a  sense,  all  else  being  equal,  a  "full  substitution"  policy  is  associated 
with  the  "cheapest"  buy  which  fulfills  the  flying  program,  while  the  "NMCS 
=  0"  policy  is  associated  with  the  "most  expensive"  buy  ("covering"  all 
failures  with  spares). 

(b)  Partial-Substitution.  In  Extended  PARC0M,  a  partial -substitution 
parts  replacement  policy  is  defined  by  partitioning  ail  part  types  into  a 
full-sub  set  and  a  no-sub  set.  A  part  type  is  in  only  one  set  and  remains 

in  that  set  throughout  the  scenario.  The  full-substitution  and  no-substitution 
policies  of  the  basic  PARC0M  are  special  cases  of  partial  substitution  in 
which  all  parts  are  either  in  the  full-sub  set  or  in  the  no-sub  set.  The 
analytic  usefulness  of  the  definition  given  below  arises  from  the  conse¬ 
quence  that  any  NMCS  aircraft  will  either  be  awaiting  exactly  one  no-sub 
part  or  at  least  one  full-sub  part  but  will  never  be  awaiting  a  mixture  of 
full-sub  and  no-sub  parts. 

•  All  parts  in  the  full-sub  set  operate  with  a  full-substitution 
replacement  policy  relative  to  aircraft  which  are  NMCS  due  to 
lack  of  a  part  from  that  set.  That  is,  a  failed  full -sub  part  on 
an  aircraft  may  be  replaced  either  by  a  spare  (if  available)  or, 
if  a  spare  is  not  available,  by  a  serviceable  part  installed  on 
an  NMCS  aircraft  which  is  awaiting  a  full-sub  part.  However,  no 
failed  full-sub  part  can  be  replaced  by  any  part  installed  on  an 
NMCS  aircraft  awaiting  a  no  sub-part. 

•  Parts  in  the  no-sub  set  operate  with  a  no-substitution  replacement 
policy.  That  is,  a  failed  no-sub  part  on  an  aircraft  may  only  be 
replaced  by  a  spare  part.  An  NMCS  aircraft  lacking  a  no-sub  part 
may  neither  receive  a  serviceable  part  from  another  NMCS  aircraft, 
nor  may  it  provide  a  serviceable  part  to  (fill  a  "hole"  in)  any 
other  NMCS  aircraft. 

(2)  Unconstrained  Costs.  With  unconstrained  costs,  a  user  has  unlimited 
funds  but  wishes  to  spend  the  least  amount  for  an  add-on  spare  buy  which 
will  enable  the  fleet  to  achieve  a  specified  goal/objective.  Within  each 
unconstrained  cost  case  the  following  options  apply: 

(a)  Goal/Objective.  The  basic  goal  is  "sparing  to  flying  hours," 
i.e.,  generating  a  parts  mix  which  will  achieve  a  specified  flying  hour 
program  at  least  cost.  An  additional  goal  of  a  minimum  required  (daily) 
aircraft  availability  can  also  be  used.  In  this  context,  aircraft  avail¬ 
ability  =  1  -  NMCS,  where  NMCS  =  the  fraction  of  surviving  aircraft  in  "not 
mission  capable  supply"  status. 
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(b)  Initial  Inventory.  For  each  item,  initial  inventory  may  be  set 
to  a  current  inventory  which  is  distributed  in  theater  according  to  a  speci¬ 
fied  schedule.  Extended  PARCOM  will  then  compute  the  least  cost  add-on 
requirement,  which  is  denoted  as  a  residual  requirements  solution.  The 
computed  requirement  is  treated  as  an  add-on  to  the  theater  war  reserve. 

The  model,  however,  can  also  generate  a  solution  with  the  initial  inventory 
set  to  zero,  which  is  denoted  as  a  total  requirements  solution. 

(3)  Constrained  Costs.  While  the  unconstrained  cost  solution  is  the 
one  that  "best"  meets  the  flying  program,  a  requirements  buy  may  not  be 
affordable  if  funds  are  limited.  With  constrained  costs,  a  user  wishes  to 
apply  limited  funds  to  buy  a  cost-effective  slice  of  the  unconstrained  cost 
requirement.  The  associated  options  are: 

(a)  Goal /Objective.  The  basic  goal  is  to  generate  a  parts  mix, 
within  the  constrained  budget,  which  maximizes  the  fraction  of  the  flying 
program  achievable.  Thus,  the  flying  program  (possibly  in  conjunction  with 
aircraft  availability  constraints)  is  a  part  of  the  goal/objective. 

(b)  Initial  Inventory.  The  residual  constrained  cost  solution 
assumes  initial  inventory  =  current  inventory  and  computes  an  add-on 
solution  based  on  an  input  cost  limit.  As  an  option,  the  mooel  can  also 
compute  a  total  requirements  solution  with  the  initial  inventory  =  0,  using 
another  input  cost  constraint. 

(4)  Treatment  of  Case  Objectives.  As  shown  in  Table  2-1,  for  each 
cost  objective  the  user  specifies  a  flying  hour  objective  and  an  availability 
objective.  For  each  of  these,  one  of  two  subobjectives  may  apply.  The 

cost  subobjectives  have  already  been  discussed.  Details  on  the  nature  of 
the  other  subobjectives  are  discussed  below. 

(a)  Maximizing  Cumulative  Flying  Hours  Achieved.  This  is  the  standard 
subobjective  met  when  running  a  constrained  cost  case.  It  entails  the  direct 
determination  of  the  parts  mix  which  will  yield  the  greatest  number  of  achieved 
flying  hours  for  a  specified  cost  limit.  The  flying  hours  achieved  will  be 
less  than  the  desired  flying  hour  program  if  the  cost  limit  is  less  than 

the  cost  of  the  unconstrained  cost  solution  mix. 

(b)  Maximizing  Consecutive  Days  of  Flying  Hour  Program  Achievement. 

This  sustainability  subobjective,  like  the  previous  one,  is  only  relevant 
in  constrained  cost  cases  (for  unconstrained  cost  cases,  achieved  flying 
hours  will  equal  programed  flying  hours,  and  consecutive  days  of  flying 
hour  program  achievement  will  equal  the  total  days  programed  for  the  assumed 
war).  The  solution  mix  meeting  a  constrained  cost/sustainability  subobjec¬ 
tive  is  obtained  through  a  two-stage  process.  First  the  user  applies  Extended 
PARCOM  to  generate  an  unconstrained  cost  solution.  The  output  list  from 
that  run  shows,  for  ^ach  day,  the  cumulative  cost  of  the  add-on  parts  that 
would  have  been  required  if  the  war  were  truncated  at  that  day.  D,  the 
last  day  on  that  list  for  which  the  associated  cumulative  cost  is  less  than 
or  equal  to  the  "cost  limit"  of  the  constrained  cost  case,  is  then  the  maxi¬ 
mum  number  of  consecutive  days  sustainable  at  100  percent  program  flying 
hours  with  "cost  limit"  spares  dollars.  Next,  the  desired  solution  mix  is 
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obtained  by  running  Extended  PARCOM  again,  in  an  unconstrained  cost  mode, 
with  a  truncated  war  of  D  days  in  length. 

(c)  Minimum  Specified  Daily  Aircraft  Availability.  This  subobjective 
is  in  addition  to  any  flying  hour  objective  and  is  operative  in  all  cases. 

The  availability  objective  may  increase  the  demand  for  available  aircraft 
beyond  those  required  to  achieve  the  flying  program.  The  input  availability 
constraints  are  used  to  calculate  daily  "allowed  NMCS  aircraft,”  which,  in 
turn,  is  used  in  all  case  calculations. 

(d)  No  Specified  Daily  Aircraft  Availability.  Extended  PARCOM  must 
always  read  in  values  for  minimum  daily  aircraft  availability  objectives; 
however,  entering  blank  or  zero  equates  to  not  specifying  an  availability. 

(5)  Capability  Value  of  Requirements  Mixes.  After  a  requirement  solu¬ 
tion  mix  is  computed.  Extended  PARCOM  will  also  generate  a  record  of  daily 
achievable  fleet  flying  capability  implied  by  use  of  that  solution  mix. 

The  capability  assessment  measures  are: 

•  Daily  achievable  aircraft  availability 

•  Daily  achievable  fraction  of  flying  program  completed 

•  Daily  achievable  flying  hours  per  available  aircraft  per  day 

Overall  average  (over  the  scenario  length)  values  of  these  measures  are 
also  computed.  In  the  requirements  mode.  Extended  PARCOM  capability  assess¬ 
ment  results  superficially  show  the  logistics  planner  cases  in  which  the 
costs  of  correcting  capability  shortfalls  are  based  only  on  filling  inventory 
shortfalls  (i.e.,  by  buying  spares).  However,  the  results  may  also  suggest 
the  need  to  examine  the  cost  effectiveness  of  other  ways  to  meet  the  flying 
program  objective.  For  example,  intensive  management  or  improved  efficiency 
in  repair  and  processing  cycles  might  reduce  requirements  by  shortening  the 
length  of  the  logistics  pipeline.  In  addition,  product  improvement  programs 
might  reduce  requirements  by  lowering  failure  rates.  Applied  with  the  con¬ 
strained  cost  option.  Extended  PARCOM  could  be  used  to  compare  improvements 
in  flying  hour  program  capability  from  applying  a  fixed  number  of  dollars, 

C,  to  "pipeline/failure  rate  improvement"  with  improvements  from  "buying 
spares."  The  capability  with  a  qualitatively  improved  current  inventory 
can  be  compared  to  the  capability  resulting  from  the  constrained  cost  solu¬ 
tion  obtained  by  using  the  C  dollars  to  efficiently  "buy  spares." 

b.  Capability  Assessment  Mode.  While  designed  primarily  as  a  require¬ 
ments  assessment  model.  Extended  PARCOM  can  also  assess  the  capability  of 
an  aircraft  fleet  with  a  specified  (e.g.,  current)  spare  inventory  to  meet 
a  flying  hour  objective  under  a  variety  of  user-specified  partial-substitution 
policies.  These  assessments  are,  depending  on  user  inputs,  in  addition  to 
or  in  place  of  results  generated  in  the  requirements  mode  described  above. 

The  user  defines  the  policies  treated  in  terms  of  the  designation  of  full-sub 
or  no-sub  parts,  as  noted  earlier.  Except  for  part  replacement  policy,  all 
scenario  conditions  are  the  same  in  all  capability  assessments.  When  the 
requirements  mode  is  also  exercised,  the  scenario  conditions  (except  for 
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replacement  policy)  specified  for  that  case  also  apply  to  all  capability 
assessment  cases.  The  assessment  measures  are  the  same  as  those  described 
above  for  capability  value  of  requirements  mixes. 

2-2.  SYSTEM  OPERATION 

a.  Extended  PARCOM  is  designed  to  operate  from  card  image  input  con¬ 
structed  by  the  user,  along  with  a  parts  data  base  in  a  format  very  similar 
to  that  used  by  the  Overview  Model  (reference  l-2g,  above)  in  the  US  Army 
Concepts  Analysis  Agency  (CAA)  Maximization  of  Flying  Hours  (MAX  FLY)  Study 
(reference  l-2h,  above).  A  peripheral  storage  device  (tape  or  disc)  is 
used  to  store  the  parts  data  base,  since  it  is  not  in  a  card-image  format. 

b.  Extended  PARCOM  output  consists  entirely  of  printed  files.  The  type 
and  quantity  of  output  can  be  controlled  to  a  degree  by  user-specified  input 
options. 

2-3.  SYSTEM  CONFIGURATION.  The  current  Extended  PARCOM  version  was  devel¬ 
oped  for  the  Sperry  1100/82  Multi -Processing  System  at  CAA.  The  model  is 
coded  in  FORTRAN. 

2-4.  SYSTEM  ORGANIZATION.  Extended  PARCOM  is  implemented  as  a  single  pro¬ 
cessor  which: 

•  Reads  part  type  data/characteristics  from  a  peripheral  storage  device. 

•  Reads  card  image  scenario  data  supplementary  to  the  parts  data.  The 
scenario  data  also  specify  the  goal /objective  for  the  solution  require¬ 
ment  mix(es). 

•  Generates  cost-effective  requirements  solution  mixes  (costs  and  compo¬ 
sition)  of  spares  based  on  the  specified  goals  and  on  a  specified 
partial-substitution  replacement  policy. 

•  Generates  achievable  combat  capability  (readiness,  flying  hours) 
reflected  in  the  solution  spares  mixes. 

•  Generates  achieveable  combat  capability  reflected  in  a  (input)  speci¬ 
fied  spares  inventory  under  a  specified  partial-substitution  replace¬ 
ment  policy. 

As  noted  earlier,  a  single  Extended  PARCOM  execution  can  generate  a  require¬ 
ments  solution  for  a  combination  of  initial  inventory  conditions,  parts 
replacement  policies,  and  cost  constraints. 

2-5.  PERFORMANCE 

a.  Input.  The  parts  data  base  for  Extended  PARCOM  is  a  modified  version 
of  the  format  used  by  the  Overview  Model,  as  applied  at  CAA.  The  data  base 
consists  of  12  records  for  each  part  type,  with  each  record  being  up  to  102 
characters  in  length.  For  the  current  maximum  capacity  of  300  part  types, 
the  Overview/PARCOM  parts  data  base  would  have  3,603  records  (3  "label" 
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records  begin  the  data  base).  However,  since  only  7  records  are  read  by 
PARCOM  from  each  "part  type"  set  of  12,  only  2,100  of  the  3,603  records  are 
used.  The  card  image  scenario  data,  for  the  current  maximum  capacity  of 
300  part  types  in  a  (maximum)  120-day  scenario,  consists  of  approximately 
40-120  records  depending  on  the  day-to-day  variation  in  specified  aircraft 
deployments,  flying  program,  and  availability  goals. 

b.  Output.  The  parts  data  input  is  "echoed,"  i.e.,  printed  in  an  output 
list.  A  variety  of  reports  on  spare  requirements  (costs  and  amounts,  total 
and  by  part  type),  and  resulting  capability  (aircraft  availability,  fraction 
of  flying  goal  achieved,  and  flying  hours  per  aircraft  per  day)  are  printed. 
For  each  demonstration  case  at  maximum  capacity,  the  volume  of  printed  output 
is  approximately  120  pages. 

c.  Limitations.  The  model  is  currently  designed  for,  at  most,  300  part 
types  processed  over,  at  most,  a  120-day  scenario.  However,  these  limits 
may  be  increased  by  altering  the  DIMENSION  and  COMMON  statements  of  the 
FORTRAN  code,  insofar  as  available  computer  memory  allows.  Further  extension 
of  capacity  can  be  achieved  by  "splitting"  Extended  PARCOM  into  several 
submodels,  each  of  which  processes  only  a  specific  problem  from  the  set  of 
problems  currently  treated  in  a  single  "run"  of  a  single  model.  With  its 
current  limits.  Extended  PARCOM  uses  47K  of  memory  on  the  Sperry  1100/82 
computer  at  CAA. 

d.  Processing  Time.  The  central  processing  time  required  for  an  Extended 
PARCOM  execution  depends  on  the  scenario  length  and  the  number  of  part  types 
processed,  as  well  as  the  types  of  problems  processed.  A  complete  Extended 
PARCOM  execution  with  the  above  limits  may  consume  up  to  13  central  proces¬ 
sing  minutes  on  the  CAA  computer. 

2-6.  DATA  BASE 

a.  The  major  portion,  in  terms  of  quantity  of  records,  of  the  Extended 
PARCOM  input  data  base  is  from  the  parts  data  base.  Extended  PARCOM  uses 
the  data  elements  shown  in  Table  2-2.  Many  of  these  are  also  used  in  the 
parts  data  base  for  the  Overview  Model.  Only  a  portion  of  the  information 
in  the  Overview  parts  data  base  is  read  and  used  by  Extended  PARCOM.  Since 
the  parts  data  base  has  records  of  102  characters  in  length,  it  is  not  read 
as  card  image  (80  characters  per  record),  and  therefore,  must  be  read  from 
a  peripheral  storage  device  (tape  or  disc). 


Table  2-2.  Data  Elements  for  Each  Part  Type  In  the  Parts  Data  Base 

(1)  National  stock  number  (NSN) 

(2)  Unit  cost 

(3)  Retail  repair  time 

(4)  Depot  repair  time 

(5)  Order  and  ship  time 

(6)  Failure  rate 

(7)  Retail  NRTS  rate 

(8)  Retail  condemnation  percentage 

(9)  Depot  condemnation  percentage 

(10)  Item  essentiality  code 

(11)  Quantity  per  application 

(12)  Part  description 

(13)  Number  of  initial  depot  serviceables 

(14)  Number  of  initial  depot  unserviceables 

(15)  Number  of  initial  war  reserve  (retail)  serviceables 

(16)  Number  of  initial  war  reserve  (retail)  unserviceables 

(17)  Total  parts  in  retail  ASL/PLLs  on  Day  1 

(18)  Distribution  schedule  of  parts  deployed  after  Day  1  (by 
5-day  intervals) 

b.  The  rest  of  the  Extended  PARCOM  input  data  base  is  denoted  by  "the 
scenario  data  base"  and  consists  of  scenario  specification  data,  scenario 
constraint  data,  additional  (to  parts  data  base)  parts  data,  and  print/ 
calculate  options.  These  are  summarized  in  Table  2-3.  These  records  are 
all  card  image.  During  Extended  PARCOM  execution  the  parts  data  base  is 
read  between  the  first  and  last  scenario  data  base  records.  Therefore,  the 
two  aforementioned  data  bases  should  always  be  read  on  separate  logical 
units  if,  as  is  now  the  case,  the  two  data  bases  are  separately  formatted 
and  constructed. 


Scenario  Specification  Data 

•  Case  identifier 

•  Length  of  war 

•  Flying  program 

•  Aircraft  deployment  schedule 

•  Aircraft  losses 

Scenario  Constraint  Data 

•  Cost  limit  (for  constrained  cost) 

•  Aircraft  availability  constraints  (minimum  daily  availability) 

•  Maximum  flying  hours  per  aircraft  per  day 

Additional  Parts  Data 

•  Order  ship  time  offset 

•  Maximum  essentiality  code  for  part  to  be  processed 

•  Lag  time  before  initial  depot  serviceables  are  sent  to  retail 

•  Duration  of  time  required  to  distribute  initial  depot  serviceables  to  retail 

Part  Replacement  Policy  Specification  Data  for  Requirement  Calculations 

•  (1st  Option)  Number  of  parts  in  full-sub  parts  set  and  the  part  numbers  of  the 
parts  designated  as  full-sub 

•  (2nd  Option)  Screening  limits  on  depot  cycle  time,  NRTS  rate,  retail  repair  time, 
and  failure  rate.  A  part  type  with  parameters  exceeding  any  screening  limit  is 
selected  for  the  full-subset. 

Part  Replacement  Policy  Specification  for  Current  Inventory  Capability  Assessment 

•  Number  of  parts  in  each  full -sub  parts  set  and  the  part  numbers  of  parts 
designated  full  sub 

Print/Calculate  Options 

•  Options  to  print  various  input/output  lists 

•  Options  to  omit  requirements  calculations  and  only  do  capability  assessment  of 
current  Inventory 

•  Option  to  select  the  order  in  which  part  requirements  are  listed  in  output— either 
by  decreasing  part  unit  cost  or  by  decreasing  amount  of  requirement 

Tuning  Parameters 

•  Desired  closeness  of  "flying  hours  flown"  convergence  during  capability  assessment 

•  Maximum  number  of  iterations  used  to  calculate  "flying  hours  flown"  during 
capability  assessment 

•  Increment  step  size  used  during  partial-substitution  requirements  calculations 

Miscellaneous 

•  Designation  of  (up  to  100)  part  types  for  which  cumulative  requirements  through 
each  scenario  day  will  be  listed 


2-7.  PARTS  DATA  BASE  FORMAT.  The  parts  data  base  read  by  Extended  PARCOM 
consists  of  3  file  header  records,  which  are  skipped,  followed  by  a  series 
of  sets  of  12  records,  each  set  being  associated  with  data  for  a  single 
part  type.  Extended  PARCOM  reads  from  only  7  of  the  12  records  in  each 
set,  the  first,  third,  fifth,  and  sixth  through  ninth  records.  The  rest 
are  skipped.  The  program  could  be  altered  to  read  a  compressed  parts  data 
package  which  could  be  constructed  by  preprocessing  an  Overview  parts  data 
base  to  "select  out"  the  elements  used  by  Extended  PARCOM.  Table  2-4  gives 
the  names,  as  used  by  the  Extended  PARCOM  READ  statement,  and  formats  of 
the  parts  data  elements  input  for  each  part  type.  "Record  number"  in  the 
table  refers  to  the  ordinal  position  of  a  data  record  within  the  12-record 
block  for  a  part  type.  "Columns  in  field"  refers  to  the  character  positions, 
within  a  record,  occupied  by  the  tabulated  data  element.  "Format"  refers 
to  the  FORTRAN  language  format  specification  currently  used.  "Description" 
is  a  summary  definition  of  the  data  element.  Note  that  some  of  these  input 
data  are  scaled  (multiplied  by  a  constant  factor). 


described  in  Table  2-4  are  associated,  via  a  subscripted  array,  with  the 
"part  number"  of  their  associated  part  type.  Currently,  the  Extended 
PARCOM  program  limits  allow  up  to  300  part  types  to  be  processed. 


Table  2-4.  Parts  Data  Record  Format 


Record 

nufcer 

PARCOM 

Columns 

In  field 

Format 

Description 

1 

Z1 

3-17 

A15 

National  stock  number  of  part 

Z2 

18-26 

F9.0 

100  *  unit  cost  (dollars)  of  part 

Z3 

32-34 

F3.0 

Order  ship  time  (days)  for  part 
(•  0  for  all  parts  In  example  data) 

Z4 

35-39 

F5.0 

1,000,000  *  failure  rate  (failures 
per  flying  hour)  for  part 

zs 

40-42 

F3.0 

NRTS  (not  repairable  this  station) 
percentage,  i.e.,  percent  of  fail¬ 
ures  sent  to  depot  for  repair 

Z6 

43-45 

F3.0 

Retail  repair  time  (days)  for  part 

Z7 

46-48 

F3.0 

Depot  repair  time  (days)  for  part 

Z8 

49-51 

F3.0 

Retail  condemnation  rate  (percent 
scrapped  at  retail  repair) 

Z9 

52-54 

F3.0 

Depot  condemnation  rate  (percent 
scrapped  at  depot  repair j 

IES 

55 

11 

Essentiality  Code  of  part  (1  *  most 
essential) 

3 

OSRV 

1-6 

F6.0 

Number  of  initial  serviceables 
located  at  depot  on  Day  1 

OUNS 

7-12 

F6.0 

Number  of  initial  unserviceables 
located  at  depot  on  Day  1 

MRS 

13-18 

F6.0 

Number  of  initial  war  reserve 
(retail)  serviceables  located  in 
theater  on  Day  1 

WRU 

19-24 

F6.0 

Number  of  initial  war  reserve 
(retail)  unserviceables  located  in 
theater  on  Day  1 

0AY1 

25-30 

F6.0 

Number  of  items  in  retail  (theater) 
ASL/PLLs  on  Day  1 

5 

IQPA 

1-2 

12 

Quantity  per  application,  i.e.,  num¬ 
ber  of  parts  installed  per  aircraft 

6 

ADSC 

1-16 

A16 

Description  of  part 

7-9 

PT(k) . 
k*l,24 

1-100 

1QF10.Q 

Number  of  items  received  (from  ASL/PLL ) 
in  theater  after  Day  1  in  each  suc¬ 
cessive  5-day  interval  k,  i.e., 

Days  5*(k-l)+l  through  5*k. 

c.  All  items  issued  or  available  during  the  scenario  should  be  included 
in  the  categories  of  Records  3  and  7-9  described  above.  If  scenarios  of 
longer  than  120  days  are  desired,  the  DIMENSION  for  variables  PT(k)  and 
PTDEP(j,k)  must  be  increased  to  allow  for  more  than  the  k=24  (=  120/5)  5-day 
intervals  currently  used. 

2-8 .  SCENARIO  DATA  BASE  FORMAT 

a.  Figure  2-2  shows  a  sample  scenario  data  base. 
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Figure  2-2.  Scenario  Data  Base 


b.  The  scenario  data  base  read  by  Extended  PARCOM  consists  of  11  sets 
of  card  image  records,  as  shown  in  Table  2-5,  which  summarize  names,  formats, 
and  descriptions.  Record  Set  1  always  has  exactly  one  card.  Record  Set  2 
has  exactly  two  cards  if  NFS  is  less  than  0,  exactly  one  card  if  NFS  =  0, 
and  at  least  two  cards  if  NFS  exceeds  0.  (The  exact  number  then  depends 
on  user  specification.)  Record  Sets  3  and  4  always  have  exactly  one  card. 

The  length  of  Record  Sets  5-11  depend  on  user  specification  as  noted  below. 
All  record  sets  must  be  present.  Aircraft  availability  constraints  are 
"omitted"  by  setting  AM  (I)  =  0  in  Record  Set  9  for  all  days.  Remarks  on 
Table  2-5  are  given  after  the  table  in  order  of  input. 


Table  2-5.  Scenario  Data  Base  Format 
(page  1  of  6  pages) 


Columns 

PARCO 

name 

Dimension 

Format 

Description 

Record  Set  1 

1-5 

ADDOST 

1 

F5.2 

Offset  (days)  added  to  order  ship 
time  read  from  parts  data  base. 

6-10 

CONVF 

1 

F5.2 

Convergence  goal  for  "flying 
hours  flown"  calculation  during 
capability  assessment  (see  Remarks) 

11-15 

IESS 

1 

15 

Maximum  Essentiality  Code  for  a 
part  type  to  be  processed. 

16-20 

DLAG 

1 

F5.0 

Depot  lag  time  (days)  before  depot 
serviceables  are  received  in 
theater  (see  Remarks). 

21-25 

DO  IS 

1 

F5.0 

Depot  distribution  time  (days)  - 
duration  of  time  over  which  depot 
serviceables  are  (uniformly)  dis¬ 
tributed  in  theater  (see  Remarks). 

Record  Set  2 

1-5 

NFS 

1 

15 

Indicator  of  the  nature  and  number 

of  the  full-sub  parts  defining  the 
partial-sub  policy.  If  NFS  >  0, 
then  the  full -sub  part  set  is 
specified  on  following  card(s). 

NFS  =  0  means  there  are  no  full-sub 
parts.  NFS  <  0  means  that  the 
full-sub  part  set  is  defined  by 
screening  thresholds  on  following 
card(s) . 


(Include  following  card  only  if  NFS  >  0) 

1-80  IFS(j)  300  1615  If  NFS  >  0,  specify  the  part  num- 

j =1 , NFS  bers  of  parts  in  the  full-sub  set. 


(Include  following  card  only  if  NFS  <  0) 


Table  2-5.  Scenario  Data  Base  Format 
(page  2  of  6  pages) 


Record  Set  2  (continued) 

1-5 

ZDCY 

1 

F5.0 

Screening  limit  (days)  on  depot 
recycle  time  (DCY).  All  parts  with 
DCY  >  ZDCY  are  designated  as  full- 
sub. 

6-10 

ZNRTL 

1 

F5.3 

Screening  limit  (fraction)  on 

NRTS  rate.  All  parts  with  NRTS  > 
ZNRTL  are  designated  as  full-sub. 

11-15 

BREPL 

1 

F5.0 

Screening  limit  (days)  on  retail 
repair  time  (BRT).  All  parts  with 
BRT  >  BREPL  are  designated  as  full- 
sub. 

16-25 

FRLIM 

1 

F10.6 

Screening  limit  (failures/flying 
hour)  on  failure  rate  (FR).  All 
parts  with  FR  >  FRLIM  are  designated 
full-sub. 

Record 

Set  3 

2-17 

CASE 

1 

A16 

Case  (run)  identification. 

Record 

Set  4 

2-15 

CLNCR 

1 

F14.0 

Add-on  cost  limit  (dollars)  for 
residual  requirement  (init  stk  = 
current  inv)  constrained  cost  case. 

16-30 

CLNCT 

1 

F15.0 

Cost  limit  (dollars)  for  total 

requirement  (irnt  stk  =  0)  con¬ 
strained  cost  case. 


Maximum  number  of  iterations  per  day 
of  "flying  hours  flown"  calculations 
during  capability  assessment  (see 
Remarks) . 


31-35  LIMIT 


1 


15 


Table  2-5.  Scenario  Data  Base  Format 
(page  3  of  6  pages) 


PARCOM 


Columns 

name 

Dimension 

Format 

Description 

Record  Set  5 

2-10 

FHM 

1 

F9.1 

Maximum  flying  hours/aircraft/day. 

11-15 

NW 

1 

15 

Number  of  days  in  war  (length  of 
scenario) . 

21-25 

ISEL 

1 

15 

If  ISEL  =  0,  only  total  (init  stk  = 

0)  requirements  will  be  done.  If 

ISEL  =  1,  only  residual  (init  stk  = 
current  inv)  requirements  will  be 
done.  If  ISEL  =  2,  both  total  and 
residual  requirements  will  be  com¬ 
puted. 

26-30 

IORD 

1 

15 

If  IORD  <  0,  the  solution  require¬ 
ments  lists  are  ordered  by  decreas¬ 
ing  part  unit  cost.  If  IORD  >  0, 
these  lists  are  ordered  by  decreasing 
amount  of  solution  requirement. 

31-35 

I0PT1 

1 

15 

If  I0PT1  <  0,  only  capability  as¬ 
sessments  of  current  inventory  will 
be  done.  If  I0PT1  >  0,  both  current 
inventory  capability  assessments  and 
requirements  cases  will  be  done. 

36-40 

I0PT2 

1 

15 

If  I0PT2  <  0,  the  full-sub  part 
numbers  used  in  the  current  inven¬ 
tory  capability  assessment  cases 
are  not  printed.  If  I0PT2  >  0,  they 
will  be. 

41-45 

I0PT3 

1 

15 

If  I0PT3  <  0,  the  no-sub  part  numbers 
used  in  the  current  inventory  cap¬ 
ability  assessment  cases  are  not 
printed.  If  I0PT3  >  0,  they  will  be. 

46-50 

I0PT4 

1 

15 

Option  ( <  0  =  omit,  >  0  =  do)  to 
print  requirements  lists  for  the 
unconstrained  cost  solution. 
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Table  2-5.  Scenario  Data  Base  Format 
(page  4  of  6  pages) 


Colunns 

PARCOM 

name 

Dimension 

Format 

Description 

Record  Set  5  (continued) 

51-55 

I0PT5 

1 

15 

Option  (<0  =  omit,  >  0  =  do)  to 
print  'cumulative  (unconstr  cost) 
requirements  costs  through  day 

N'  list. 

56-60 

IPRT 

1 

15 

Option  (<0  =  omit,  >  0  =  do)  to 
print  the  scenario  input  data 
summary. 

61-65 

IPRT1 

1 

15 

If  IPRT1  <  0,  the  full-sub  and  no¬ 
sub  part  sets  used  in  requirements 
cases  will  not  be  printed,  nor  will 
part  input  data  list  summaries  after 
the  first  one.  If  IPRT1  >  0,  these 
will  be  printed. 

Record  Set  6 

1-5 

NACDEP 

1 

15 

Number  of  day  intervals  (see  I DAY ( I ) 
below)  for  which  aircraft  deployments 
are  specified. 

1-80 

I DAY ( I) 

61 

1615 

Initial  day  of  interval  (in  in¬ 
creasing  order)  for  specified  (by 

NAC(I)  below)  aircraft  deployment. 

1-80 

NAC(I) 

61 

1615 

Cumulative  number  of  aircraft  de¬ 
ployed  by  I DAY ( I ) .  These  are  input 
in  the  same  order  as  IDAY(I).  NAC(I) 
applies  from  day  I DAY ( I )  through  day 
IDAY(I+1)-1,  or  (for  the  last  interval) 
through  day  NW. 

Record  Set  7 

1-5  NFHDAY  1  15  Number  of  day  intervals  for  which 

daily  program  flying  hours  are 
specified. 


2-15 


Table  2-5.  Scenario  Data  Base  Format 
(page  5  of  6  pages) 


PARCOM 


Columns 


name 


Dimension 


Format 


Description 


Record  Set  7  (continued) 


1-80 

IDAY(I) 

61 

1615 

Initial  day  of  interval  (in  in¬ 
creasing  order)  for  specified  (by 
NFH(I)  below)  program  flying  hours. 

1-80 

NFH(I) 

61 

1615 

Daily  program  flying  hours  for 
each  day  from  IDAY(I)  through  the 
day  before  IDAY(I+1),  or  through 
day  NW. 

Record 

Set  8 

1-5 

NLDAY 

1 

15 

Number  of  day  intervals  for  which 
daily  aircraft  attrition  losses 
are  specified. 

1-80 

I DAY ( I) 

61 

1615 

Initial  day  of  interval  (in  in¬ 
creasing  order)  for  specified 
daily  aircraft  losses. 

1-80 

ZLOSS(I) 

61 

16F5.1 

Daily  aircraft  losses  for  each  day 
from  IDAY(I)  through  the  day  before 
IDAY(I+1),  or  through  day  NW. 

Record  Set  9 

1-5 

NMDAY 

1 

15 

Number  of  day  intervals  for  which  a 
"minimum  required  aircraft  avail¬ 
ability"  is  specified. 

1-80 

I DAY ( I ) 

61 

1615 

Initial  day  of  interval  (in  in¬ 
creasing  order)  requiring  specified 

"minimum  required  aircraft  avail 
abi 1 ity. " 

Daily  "minimum  required  aircraft 
availability"  for  each  day  from 
IDAY(I)  through  the  day  before 
IDAY(I+1),  or  through  day  NW. 


1-80  AM( I ) 


61 


1615 


Table  2-5.  Scenario  Data  Base  Format 
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Columns 

PARCOM 

name 

Dimension 

Format 

Description 

Record  Set  10 

1-5 

IMSEL 

1 

15 

The  number  of  part  types  for  which 
"cumulative  requirement  for  each 
day"  will  be  printed  in  the  Cumu¬ 
lative  Stock  Requirement  List  for 
Selected  Items.  IMSEL  must  be  <  100. 

1-80 

IPT(K) 

100 

1615 

The  "part  numbers"  (from  echoed  Part 
Input  Data  List)  of  the  specified 
(IMSEL)  part  types  to  be  represented 
in  the  Cumulative  Stock  Requirement 
List  for  Selected  Items. 

Record  Set  11  (see  Remarks) 

1-5 

NPTFS 

1 

15 

Number  of  full -sub  parts  designated 
for  this  partial-sub  policy  used 
only  in  capability  assessment  of 
current  inventory.  If  NPTFS  >  0, 
then  you  must  set  NPTNS  <  0. 

6-10 

NPTNS 

1 

15 

Number  of  no-sub  parts  designated 
for  this  partial-sub  policy  used 
only  in  capability  assessment  of 
current  inventory.  If  NPTNS  0, 
then  you  must  set  NPTFS  0. 

1-80 

IFS(J)  300 

for  J=l, NPTFS 
or  INS(J) 
for  J=l, NPTNS 

1615 

If  NPTFS  >  0,  these  are  the  part 
numbers  of  the  full-sub  parts  in 
this  partial-sub  policy  used  only 
for  capability  assessment  of  cur¬ 
rent  inventory.  If  NPTNS  >  0,  these 
are  the  part  numbers  of  the  no-sub 
parts  in  the  policy. 
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2-9.  REMARKS  ON  SCENARIO  DATA  BASE.  The  following  remarks  amplify  and 
clarify  the  meaning  and  use  of  selected  elements  of  the  Scenario  Data  Base 
defined  in  Table  2-5: 


•  Record  Set  1 

••  ADDOST  was  needed  in  Extended  PARCOM  demonstration  runs  only 
because  the  Overview  parts  data  base  used  by  CAA  had  a  zero 
entry  for  order  ship  time.  A  properly  constructed  Overview 
parts  data  base  would  use  ADDOST  =  0. 

••  CONVF  should  be  set  to  a  small  positive  number  less  than  .05. 
8oth  CONVF  and  LIMIT  determine  duration  of  capability  assess¬ 
ment  processing  for  constrained  cost. 

••  IESS  could  be  set  *  1  for  a  parts  data  base  in  which  all  "essen¬ 
tial  items"  are  coded  1. 

••  DLAG  and  DDIS  apply  to  all  parts.  The  depot  serviceables  en¬ 
tered  in  the  parts  data  base  (DSRV  in  Table  2-4)  are  received 
in  theater  between  Day  DLAG+1  and  Day  (DLAG+DDIS) . 

•  Record  Set  2 

••  If  NFS  >  0,  the  parts  in  the  full-sub  set  must  be  specified  in 
terms  of  the  "part  numbers"  generated  internally  in  Extended 
PARCOM.  These  are  printed  in  the  model  output.  If  NFS  =  0, 
only  one  card  (specifying  NFS)  is  in  this  record  set.  If 
NFS  <  0,  all  four  screening  thresholds  must  be  specified.  If 
a  limit  is  "not  used,"  its  value  must  be  set  high  enough  so 
that  al 1  parts  have  the  associated  attribute  below  the  limit; 
e.g.,  if  only  parts  with  NRTS  >  .50  and  retail  repair  time  > 

29  days  are  to  be  substitutable,  set  ZNRTL  =  .50  and  BREPL  = 

29  and  set  ZDCY  high  enough  so  that  all  part  depot  recycle 
times  are  less  than  ZDCY  and  set  FRLIM  >  1.0  (because  all  fail¬ 
ure  rates  will  be  less  than  1).  Recall  that  depot  recycle 
time  =  2  *  OST  +  depot  repair  time. 

•  Record  Set  4 

••  CLNCR  and  CLNCT  can  be  used  to  suppress  the  processing  of  the 
constrained  cost  case  by  setting  them  to  negative  values;  e.g., 
if  CLNCR  <  0,  then  the  residual  (add-on)  requirements  for  the 
constrained  cost  case  will  not  be  done. 

••  LIMIT  should  normally  be  set  to  4  or  less.  A  high  value  of 
LIMIT  increases  processing  time  for  capability  assessment. 

The  higher  the  value  of  LIMIT,  the  closer  is  the  convergence 
of  "flying  hours  flown"  in  the  capability  assessment  calcula¬ 
tion.  The  closeness  is  printed  in  the  model  output,  so  the 
user  has  a  guide  for  "trial  and  error"  tests. 
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•  Record  Set  6 


•• 


The  NAC(I)  must  be  input  in  the  same  order  as  the  I DAY ( I ) . 
Similar  remarks  apply  to  Record  Sets  7-9. 


•  Record  Set  7 


M  For  I  =  NFHDAY,  NFH(I)  is  the  daily  flying  hours  from  I DAY ( I ) 
through  NW  (end  of  war).  Similar  remarks  apply  to  Record  Sets 
8-9. 


•  Record  Set  9 

••  "No  availability  constraint"  can  be  modeled  by  having  one  inter 
val  ( NMDAY  =  1)  with  IDAY(l)  =  1,  and  AM(1)  =  0. 

•  Record  Set  10 

••  IMSEL  must  be  less  than  or  equal  to  100. 

••  The  "part  numbers"  for  IPT(K)  must  be  the  internal  Extended 
PARCOM  subscripts  for  the  specified  part  types.  These  are 
printed  in  the  Parts  Input  Data  List  at  the  beginning  of  output 
where  the  entire  part  data  base  is  "echoed"  with  the  "part 
number"  appended  for  those  parts  processed.  Data  on  parts  not 
processed  are  also  printed  in  that  list,  but  no  part  number  is 
appended. 

•  Record  Set  11 

••  A  sequence  of  partial-sub  policies  for  capability  assessment 
may  be  input.  Input  for  each  policy  is  as  described  above, 
viz:  one  card  giving  either  NPTFS  or  NPTNS  (but  not  both), 
followed  by  cards  specifying  the  part  numbers  designated 
full-sub  (if  NPTFS  <  0)  or  no-sub  (if  NPTNS  >  0).  If  full-sub 
parts  are  designated,  all  parts  not  designated  are  no-sub  by 
default  and  vice  versa.  Input  order  of  part  numbers  is  irrele¬ 
vant.  Part  numbers,  as  before,  refer  to  Extended  PARCOM  part 
numbers.  If  record  set  11  is  omitted,  only  the  single  (input) 
policy  will  be  used  in  assessment. 
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CHAPTER  3 
MODEL  OUTPUT 


3-1.  INPUT  CONSTRAINTS.  The  user  can  limit  the  amount  of  output  produced 
by  the  values  assigned  to  the  inputs  I0PT1,  I0PT2,  I0PT3,  I0PT4,  I0PT5, 
IPRT,  and  IPRT1  as  described  in  Table  2-5.  In  addition,  any  case  can  be 
truncated  by  setting  input  NW  (number  of  days  in  war)  to  a  suitably  low 
value. 


3-2.  SCOPE  OF  CASES  PROCESSED 

a.  Cases  Processed.  Figure  3-1  shows  types  of  cases  processed  in  a 
single  Extended  PARCOM  run.  The  subdivisions  represent  parametric  varia¬ 
tions  in: 

•  Type  result  -  requirements  or  capability  assessment. 

•  Cost  constraints  -  with/without. 

•  Initial  inventory  of  parts  -  zero  or  as  specified  (usually 
current) . 

•  Parts  replacement  policy  (capability  assessment  cases  only). 

Entries  shown  as  "XXX"  indicate  user-defined  input  values.  Figure  3-1 
graphically  represents  a  "nested  umbrella"  of  conditions  defining  each  of 
the  cases  generated  for  a  specified  scenario,  i.e.,  all  blocks  above  Case 
ID  in  the  chart  state  the  defining  conditions  of  that  case.  These  are  also 
implicit  in  the  Case  ID,  interpreted  as  follows: 

First  character: 

T  =  full  (total)  requirements,  R  =  add-on  (residual)  requirements,  C  = 
capability  assessment  only. 

Second  character  -  cost  constraints: 

U  =  unconstrained,  C  =  constrained,  F  =  fixed  inventory  (capability 
assessment  only) . 

Third  character: 

Partial-substitution  replacement  policy  designator. 

Capability  assessment  of  current  inventory  can  be  done  in  a  single  "run" 
for  a  number  of  different  partial-substitution  policies,  as  specified  by 
user  input.  However,  requirements  results  can  be  generated  for  only  a  sin¬ 
gle  user-specified  partial-substitution  policy  per  model  run.  Note  that 
the  "full  requirements"  case  is  equivalent  to  initial  inventory  =  0,  while 
the  "add-on  requirements"  case  is  equivalent  to  initial  inventory  =  current 
inventory  (or  as  otherwise  entered).  Using  this  notation,  RUl  for  the  se¬ 
lected  scenario  represents  the  case:  residual  (add-on)  requirements. 
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unconstrained  costs,  and  the  specified  partial-substitution  parts  replace 
ment  policy,  e.g.,  1. 


aThe  daily  flying  hour  fraction  «  1.00  for  all  days  if  the  unconstrained  cost  solution  requirement  is 
stocked. 


Figure  3-1.  Type  Outputs  Produced  for  Each  Case 
Within  an  Extended  PARCCM  Scenario 


b.  Summary  of  Output.  Figure  3-1  also  shows  the  available  output  pro 
duced  for  each  case  generated  within  an  Extended  PARCOM  scenario.  An  "X" 
in  the  matrix  indicates  availability  of  the  type  output,  described  in  the 
left  margin,  for  the  case  with  the  "Case  ID"  shown  above  the  "X".  Shaded 
boxes  are  for  inapplicable  outputs.  A  brief  description  of  each  type  out 
put  is  given  below.  A  complete  descriptive  listing  of  PARCOM  output 
tables,  with  samples,  is  given  in  paragraph  3-3. 
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(1)  Requirement  Mix,  Costs.  For  the  total  (initial  inventory  =  0) 
case,  this  shows  the  least-cost  parts  mix  and  cost  required  to  achieve  the 
flying  program  (unconstrained  dollars),  or  total  "best"  parts  mix  purchas¬ 
able  with  the  budget  limit  (constrained  dollars).  For  the  residual  (initial 
inventory  =  current  inventory)  case,  this  shows  the  least-cost  add-on  parts 
mix  and  cost  which  will  achieve  the  flying  program  (unconstrained  dollars), 
or  the  "best"  add-on  buy  to  initial  inventory  within  the  cost  limit  (con¬ 
strained  dollars). 

(2)  Cumulative  Cost  by  Day.  For  each  Day  N,  the  total  cost  of  the 
parts  requirement  to  sustain  the  scenario  flying  program  through  Day  N  only, 
i.e.,  it  is  the  total  requirement  cost  for  a  truncated  scenario  of  N  days 

in  length. 

(3)  Cumulative  Requirement  by  Day.  For  selected  items  for  each  Day 
N,  the  cumulative  requirement  for  each  item  needed  for  the  flying  program 
to  be  sustained  through  N  days. 

(4)  Daily  Aircraft  Availability.  For  each  day  of  the  full  scenario, 
the  fraction  of  surviving  aircraft  which  are  not  NMCS  assuming,  for  require¬ 
ments  cases,  that  the  initial  spare  inventory  is  augmented  by  the  computed 
parts  requirement. 

(5)  Daily  Flying  Hour  Fraction.  For  each  day  of  the  full  scenario, 
the  fraction  of  the  fleet  flying  program  which  can  be  achieved  assuming, 
for  requirements  cases,  that  the  initial  spare  inventory  is  augmented  by 
the  computed  parts  requirement. 

(6)  Daily  Flying  Hours  per  Available  Aircraft  per  Day.  For  each  day 
of  the  full  scenario,  the  achieved  program  flying  hours  per  aircraft 
assuming,  for  requirements  cases,  that  the  initial  spare  inventory  is  aug¬ 
mented  by  the  computed  parts  requirement. 

3-3.  SAMPLE  OUTPUTS.  A  complete  list  of  standard  outputs  is  presented 
below  in  the  sequence  of  output.  User-controlled  input  options  can  suppress 
the  printing  of  many  of  these  lists.  Figures  of  sample  outputs  and  descrip¬ 
tive  explanations  are  given.  For  convenience,  the  sample  outputs  are  re¬ 
stricted  to  a  case  involving  four  part  types  over  a  5-day  war.  The  order 
of  outputs  is: 

a.  Input  Data.  The  following  series  of  outputs  gives  comprehensive 
summaries  of  the  input  data  entered  by  the  user  in  the  Parts  Data  Base  and 
the  Scenario  Data  Base. 

(I)  Parts  Input  Data  List  (Figure  3-2).  The  raw  parts  data  is  "echoed" 
in  labeled  form.  The  order  of  parts  is  as  input.  The  entries  under  the 
PART  heading  are  the  "part  numbers"  which  are  cross-referenced  in  other 
lists.  MSN  denotes  the  stock  number  ID  (usually  the  national  stock  number) 
input  in  the  Parts  Data  Base.  COST  denotes  unit  cost  of  the  part.  OST 
denotes  the  order/ship  time  in  days.  FAIL  RT  denotes  failure  rate  in  fail¬ 
ures  per  flying  hour.  NRTS  gives  the  "not  repairable  this  station"  fraction. 
BCY  denotes  the  base  repair  time  (in  days).  DCY  denotes  the  depot  cycle 


3-3 


CAA-0-85-2 

time  in  days,  i.e.,  the  time  from  removal  until  return  from  depot  repair. 

It  is  the  sum  of  the  depot  repair  time  and  2  x  OST.  DRT  denotes  depot  repair 
time.  BOON  denotes  the  fraction  of  failed  parts  which  are  condemned  (scrap¬ 
ped)  at  retail  repair.  DCON  denotes  the  fraction  of  failed  parts  sent  to 
depot  repair  and  subsequently  condemned  at  that  level  of  repair.  QPA  denotes 
the  quantity  per  application  for  the  part,  i.e.,  the  number  of  units  of 
that  part  type  installed  per  operational  aircraft.  ESS  denotes  the  essen¬ 
tiality  code  of  the  part.  CLASS  shows  whether  the  part  is  designated  as  a 
full-sub  part  or  a  no-sub  part,  as  specified  via  the  Scenario  Data  Base 
(Record  Set  2  in  Chapter  2,  Table  2-5).  While  all  part  data  is  “echoed"  in 
this  list,  only  those  parts  with  nonzero  failure  rates  and  with  essentiality 
code  less  than  or  equal  to  a  user-specified  level  (IESS)  are  assigned  part 
numbers.  Listed  part  data  not  assigned  a  part  number  are  not  subsequently 
processed.  After  the  last  item  of  the  parts  list,  the  total  number  of  input 
part  types  (TOTAL  NR  PARTS)  is  given  along  with  the  number  of  these  part 
types  to  be  processed  by  PARCOM  (NR  USED).  The  IN IT  STK  column  shows  the 
initial  stock  in  place  at  theater  on  Day  1.  It  reflects  the  sum  of  spare 
assets  in  serviceable  war  reserves  (WRS  in  Table  2-4)  and  in  theater  ASL/PLLs 
on  Day  1  (DAYl  in  Table  2-4). 
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Figure  3-2.  Parts  Input  Data  List 


(2)  Full-sub  Parts  List  for  Requirements  Cases  (Figure  3-3).  This 
list  displays,  in  order  of  input,  data  for  those  parts  designated  as  in  the 
full-sub  parts  set  used  in  requirements  cases.  The  data  shown  is  extracted 
(sorted)  from  the  Parts  Input  Data  List.  This  list  is  printed  only  if  a 
positive  value  for  IPRT1  is  input  in  the  Scenario  Data  Base. 
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Figure  3-3.  Full -sub  Parts  List  for  Requirements  Cases 
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(3)  No-sub  Parts  List  for  Requirements  Cases  (Figure  3-4).  This  list 
displays,  in  order  of  input,  data  for  those  parts  in  the  no-sub  parts  set 
used  in  requirements  cases.  The  user  designates  the  full-sub  part  set. 
Extended  PARCOM  then  puts  all  nondesignated  parts  in  the  no-sub  set.  The 
full-sub/no-sub  partition  of  the  parts  data  defines  the  partial-substitution 
policy.  All  data  shown  is  extracted  (sorted)  from  the  Parts  Input  Data 
List.  This  list  is  printed  only  if  a  positive  value  for  IPRT1  is  input  in 
the  Scenario  Data  Base. 
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Figure  3-4.  No-sub  Parts  List  for  Requirements  Cases 


(4)  Input-ordered  Cost/Stockage  List  (Figure  3-5).  This  list  shows 
the  unit  cost  and  inventory  for  each  part  processed.  Parts  are  in  order  of 
input.  Part  numbers  shown  are  defined  as  in  paragraph  3-3a(l)  above.  The 
rank  heading  is  redundant  here,  but  is  subsequently  used  in  presenting  this 
data  ordered  by  part  unit  cost.  The  part  numbers  are  cross-referenced  with 
those  in  the  Part  Input  Data  List.  The  distribution  of  the  entire  initial 
inventory  for  each  part,  as  input  in  the  Parts  Data  Base,  is  summarized  in 
terms  of  initial  serviceables  at  depot  (DSERV),  initial  unserviceables  at 
depot  (DUNSR),  theater  war  reserve  serviceables  (WRSRV),  theater  war  reserve 
unserviceables  (WRUNS),  ASL/PLL  stocks  in-place  on  Day  1  (DAYl),  and  ASL/PLL 
deployed  after  Day  1  (DAY2-).  The  total  noncondemned  stock  (TOT  NC)  is 
also  shown.  This  total  may  be  less  than  the  sum  of  the  other  entries  since 
some  unserviceable  stocks  may  be  condemned.  This  list  is  printed  only  if 
IPRT1  is  set  to  a  positive  value  in  the  Scenario  Data  Base. 
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Figure  3-5.  Input -ordered  Cost/Stockage  List 
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(5)  Unadjusted  Parts  Deployment  List  (Figure  3-6).  This  list  shows 
the  scheduled  arrivals  of  ASL/PLL  stocks  which  were  not  in  place  on  Day  1. 
Arrivals  are  by  5-day  interval,  according  to  the  key  at  the  top  of  the  figure 
(e.g.,  -25  refers  to  the  period  between  Day  21  and  Day  25).  Each  part  is 
identified  by  a  leading  line  showing  the  part  number,  the  national  stock 
number  (NSN),  and  the  part  description,  as  input  in  the  Parts  Data  Base. 

The  sum  of  the  entries  for  each  part  should  equal  the  DAY2-  entry  in  Figure 
3-5.  In-place  ASL/PLL  and  depot  stocks  are  not  included  in  this  list. 
Scheduled  arrivals  after  Day  120  are  ignored  and  are  not  recorded  in  this 
list.  This  list  is  printed  only  if  IPRT1  is  set  to  a  positive  value  in  the 
Scenario  Data  Base. 
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Figure  3-6.  Unadjusted  Parts  Deployment  List 


(6)  Adjusted  Parts  Deployment  List  (Figure  3-7).  This  list  shows 
scheduled  arrivals  in  theater  of  all  stocks  not  in  theater  on  Day  1.  Arri¬ 
vals  are  by  5-day  interval,  keyed  as  in  Figure  3-6.  In  this,  as  in  the 
previous  figure,  only  arrivals  through  Day  120  are  recorded.  If  the  scenario 
used  is  shorter  than  120  days,  only  arrivals  during  the  scenario  period 
will  affect  results.  The  total  of  entries  in  this  figure,  for  each  part, 
should  equal  the  total  noncondemned  inventory  (TOT  NC  entry  in  Figure  3-5) 
less  the  in-place  theater  stocks  on  Day  1  (the  sum  of  the  WRSRV  and  the 
DAY1  entries  in  Figure  3-5).  The  list  is  denoted  as  "adjusted"  because  it 
adjusts  the  previous  list  (Figure  3-6)  by  adding  in  the  distributions  from 
depot  stocks  and  from  initially  unserviceable  war  reserves. 
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Figure  3-7.  Adjusted  Parts  Deployment  List 
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(7)  Scenario  Input  Data  Summary  (Figure  3-8).  This  output  "echoes" 
much  of  the  scenario  input  data.  It  includes  a  table  showing,  on  a  daily 
basis,  the  cumulative  aircraft  deployed,  the  program  flying  hours,  the  mini¬ 
mum  aircraft  availability  objective,  the  aircraft  lost  (attrition),  and  the 
cumulative  aircraft  lost.  This  table  has  sufficient  information  to  enable 
the  model  user  to  convert  a  PARCOM-generated  aircraft  availability  into 
"number  of  aircraft  available"  and  a  "fraction  flying  hour  program  achieved" 
into  "number  of  program  hours  achieved".  Also  shown  is  the  dollar  value  of 
the  total  initial  inventory  of  parts  processed.  Note  that  this  amount  ex¬ 
cludes  parts  in  the  data  base  which  are  not  processed  (because  of  zero  fail¬ 
ure  rate  or  inappropriate  essentiality  code).  For  parts  processed,  valuation 
is  determined  by  accumulating  the  product  of  initial  inventory  and  part 
unit  cost. 
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Figure  3-8.  Scenario  Input  Data  Summary 


(8)  Options  Report  (Figure  3-9).  This  output  shows  and  explains  the 
options  set  by  the  user  in  Record  Set  5  of  the  Scenario  Data  Base.  In  addi- 
!  *  tion,  the  value  of  NFS  from  Record  Set  2  is  also  shown.  When  NFS  is  less 

than  zero,  this  report  also  shows  the  screening  thresholds  used  to  select 
the  full-sub  part  set.  The  value  of  INT  is  set  equal  to  1  internally  and 
;  is  not  specified  by  the  input  data. 
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Figure  3-9.  Options  Report 


(9)  Cost-ordered  Parts  List  (Figure  3-10).  This  list  shows  part  num¬ 
ber,  part  description,  and  part  unit  cost  ranked  in  decreasing  order  of 
part  unit  cost.  RANK  denotes  the  rank  order  (over  all  processed  part  types). 
PART  denotes  the  associated  part  number  (as  defined  in  paragraph  3-3a( 1 ) ) . 
Also  shown  is  the  designation  of  the  part  as  either  a  full-sub  or  a  no-sub 
part,  as  specified  by  Record  Set  2  of  the  Scenario  Data  Base. 
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b.  Total  Requirements  Case  Results.  The  following  outputs  are  for  the 
case  with  zero  initial  inventory.  The  computed  requirements  are  assumed 
stocked  in  theater  (this  is  in  contrast  to  the  residual  requirements  case 
in  which  initial  stocks  are  distributed  over  a  specified  schedule).  Results 
for  total  requirements  are  generated  only  if  ISEL  =  0  or  2  in  the  Scenario 
Data  Base. 

(1)  Unconstrained  Dollar  Total  Requirements  Total  Cost  List  (Figure 
3-11).  The  output  shows  the  total  cost  of  the  least-cost  total  requirements 
unconstrained  cost  solution  (based  on  zero  initial  inventory)  for  the  speci¬ 
fied  partial-sub  policy.  Costs  are  computed  by  cumulating  the  product  of 
part  unit  cost  and  total  units  (of  part)  required.  The  partial-sub  policy 
is  defined  by  the  full-sub/no-sub  partition  of  parts,  as  specified  by  the 
user  in  Record  Set  2  of  the  Scenario  Data  Base. 
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Figure  3-11.  Unconstrained  Dollar  Total  Requirements  Total  Cost  List 


(2)  Unconstrained  Dollar  Total  Requirements  Parts  List  (Figure  3-12). 

The  output  shows  the  composition  of  the  total  unconstrained  cost  requirement 
solution  mixes  (zero  initial  inventory)  for  the  specified  policy.  Parts 
requirements  are  listed  here  in  order  of  decreasing  amount  of  requirements 
(because  IORD  =  1  in  this  example).  For  each  part  and  policy  is  listed: 

(a)  The  Extended  PARCOM  part  number  and  part  description. 

.(b)  The  number  of  units  of  that  part  required  to  achieve  the  case 
objective  under  the  indicated  policy.  A  zero  initial  inventory  is  assumed 
in  the  "total  requirements"  case. 

(c)  The  cost  of  the  requirement  computed  as  the  product  of  units 
required  and  part  unit  cost. 

(d)  The  percent  of  the  overall  (i.e.,  overall  parts)  requirement 
represented  by  the  requirement  for  the  part  type. 
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Figure  3-12.  Unconstrained  Dollar  Total  Requirements  Parts  List 


(3)  Selected  Items  Cumulative  Total  Requirement  List  (Figure  3-13). 

The  output  consists  of  the  total  (zero  initial  inventory)  unconstrained 
cost  requirement  for  each  of  up  to  100  selected  part  types  for  a  truncated 
scenario  of  length  N  days,  where  N  =  1,  2,  ...  through  the  last  day  of  the 
base  case  scenario.  Each  row  of  output  corresponds  to  the  unconstrained 
cost  total  requirement  for  a  "war"  of  length  N  as  noted  in  the  leftmost 
(DAY)  column.  Excluding  that  column,  each  column  gives  the  requirement  for 
the  part  identified,  by  description  and  NSN,  in  the  heading  of  each  column. 
The  selected  parts  are  specified  by  user  input  in  Record  Set  10  of  the  Sce¬ 
nario  Input  Data  Base.  The  tabulated  requirements  represent  an  extract 
from  the  requirements  computed  over  the  full  part  data  base  (not  over  just 
the  part  types  shown).  Therefore,  the  last  entry  for  each  part  in  this 
list  should  be  the  same  as  the  requirement  in  the  Unconstrained  Dollar  Total 
Requirements  Parts  List.  The  purpose  of  the  output  list  is  to  allow  the 
user  to  examine  the  changing  demand,  over  time,  for  certain  key  parts  under 
the  specified  partial-sub  policy. 
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Figure  3-13.  Selected  Items  Cumulative  Total  Requirement  List 


(4)  Total  Requirement  Cumulative  Cost  List  (Figure  3-14).  The  output 
consists  of  the  total  cost  (all  parts)  of  the  total  unconstrained  cost  re¬ 
quirements  solution  (zero  initial  stock)  applied  in  a  truncated  scenario 
consisting  of  the  first  N  days  of  the  base  scenario,  where  N  =  1,  2,  ... 
through  the  last  day  of  the  base  scenario.  The  leftmost  column  shows  the 
last  day  of  the  truncated  scenario  while  the  entry  on  the  same  line  shows 
the  total  requirement  cost.  As  before,  total  cost  consists  of  the  product 
of  units  required  and  part  unit  cost,  summarized  over  all  part  types  pro¬ 
cessed.  The  cost  on  the  last  line  (day)  of  the  output  list  should  be  the 
same  as  that  in  the  Unconstrained  Dollar  Total  Requirements  Total  Cost  List 
(Figure  3-11).  Another  interpretation  of  this  output  is  that  it  gives,  for 
each  policy,  the  expected  cost  for  total  requirements  required  to  sustain 
the  flying  hour/availability  objective  through  any  specified  day  of  the 
scenario.  After  the  last  day's  entry  on  the  table,  a  summary  of  the  cost 
limit  applied  in  the  constrained  cost  algorithm  2  is  given.  That  algorithm 
computes  a  sustainability  solution,  i.e.,  one  which  maximizes  consecutive 
days  of  flying  hour  program  achievement.  The  input  cost  limit  is  printed, 
along  with  the  cumulative  cost  entry  and  the  last  day  for  which  the  associ¬ 
ated  cost  is  less  than  the  input  cost  limit  (see  paragraph  2-la(4)). 
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Figure  3-14.  Total  Requirement  Cumulative  Cost  List 


(5)  Unconstrained  Dollar  Total  Requirements  Force  Capability  List 
(Figure  3-15).  The  output  shows,  as  discussed  below,  expected  achievable 
daily  aircraft  availability,  the  "driving"  factor  in  determination  of  avail 
ability  objective,  and  flying  hours  per  available  aircraft  per  day  for  the 
specified  partial-substitution  policy,  assuming  that  the  computed  "uncon¬ 
strained  dollar  total  requirement"  (listed  in  Figure  3-12)  is  stocked  and 
available  on  Day  1.  The  input  used  to  distribute  current  stock  over  time 
is  not  applied  in  this  case,  in  which  a  zero  current  stock  is  assumed.  How 
ever,  it  is  applied  in  the  residual  (add-on)  requirements  case. 
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Figure  3-15.  Unconstrained  Dollar  Total  Requirements 
Force  Capability  List 


(a)  Aircraft  Availability.  Aircraft  availability,  as  applied  in 
Extended  PARCOM,  is  defined  as  the  fraction  of  surviving  aircraft  which  are 
not  in  NMCS  status.  The  minimum  aircraft  availability  required  on  each  day 
in  order  to  meet  the  case  objective  is  shown  under  the  REQ  AVAIL  heading. 

The  required  availability  must  equal  the  larger  of  the  availability  reflected 
in  the  daily  flying  hour  program  and  that  specified  by  the  input  availability 
constraints.  An  initial  aircraft  availability  of  1.00  is  assumed. 

(b)  Availability  Source.  The  "driving"  source  of  the  daily  availa¬ 
bility  requirement  is  listed  under  the  AVAIL  SOURCE  heading.  FLYING  HR 
PROGRAM  denotes  the  daily  flying  hour  program  while  AVAIL  CONSTRAIN  denotes 
an  input  availability  constraint.  In  the  AVAIL  column  immediately  to  the 
right  of  the  AVAIL  SOURCE  entries  are  the  daily  input  availability  constraints 
input  by  the  user.  When  the  AVAIL  SOURCE  is  AVAIL  CONSTRAIN,  these  availabil¬ 
ities  should  be  identical  to  corresponding  entries  in  the  REQ  AVAIL  column. 

(c)  Flying  Hours  per  (Available)  Aircraft  per  Day.  These  entries 
are  computed  by  dividing  the  number  of  program  flying  hours  for  the  day  by 
the  number  of  available  aircraft  on  that  day.  The  number  of  available  air¬ 
craft  is  just  the  product  of  the  tabulated  aircraft  availability  and  the 
number  of  surviving  aircraft. 


(d)  Averages  Over  Time.  After  all  daily  status  figures  are  listed. 
Extended  PARCOM  prints  averages  for  achieved  aircraft  availability,  minimum 
required  availability,  and  achieved  flying  hours  per  aircraft  per  day.  These 
are  all  weighted  averages  over  time.  In  calculating  the  weighted  averages, 
each  daily  availability  entry  is  weighted  by  the  number  of  surviving  aircraft 
on  that  day,  and  each  daily  "flying  hour  per  aircraft  per  day"  entry  is 
weighted  by  the  number  of  available  aircraft  on  that  day. 

(6)  Constrained  Cost  Total  Requirements  Solution  Evaluation  Report 
(Figure  3-16).  This  output  summarizes  the  process  by  which  a  constrained 
cost  solution  is  computed  for  the  total  requirements  case.  The  process  is 
described  in  a  technical  paper  (see  reference  l-2e  in  Chapter  1).  If  the 
input  cost  limit  exceeds  the  cost  of  the  unconstrained  cost  solution,  then 
this  report  states  that  the  unconstrained  cost  solution  is  also  the  con¬ 
strained  cost  solution  and  stops  further  constrained  cost  processing.  In 
the  more  typical  case  (shown),  two  different  constrained  cost  algorithms, 
denoted  herein  as  algorithm  1  and  algorithm  2,  will  be  applied  to  produce 
two  separate  solutions  and  the  preferred  solution  will  be  returned  and  listed 
on  the  report  following  this  one.  Algorithm  1  first  "buys"  as  many  no-sub 
parts  from  the  unconstrained  cost  solution  as  are  affordable.  The  first 
line  of  the  report  then  indicates  how  much  of  the  cost  limit  can  be  used  to 
do  this.  Algorithm  1  then  uses  the  money  left  over  to  "buy"  full-sub  parts 
from  the  unconstrained  cost  solution.  If  not  all  no-sub  parts  are  afford¬ 
able,  the  amount  "spent"  is  shown  (as  here)  followed  by  a  statement  that  no 
full -sub  parts  are  affordable.  However,  if  all  no-sub  parts  are  affordable, 
the  first  report  line  then  simply  notes  that,  and  is  followed  by  a  line 
indicating  how  much  of  the  cost  limit  can  then  be  used  to  buy  full-sub  parts. 
The  algorithm  2  requirements  solution  is  also  computed,  but  no  reports  on 
its  calculation  process  are  printed.  The  last  two  report  lines  show  the 
average  fraction  of  flying  program  achieved  based  on  stockage  of  the  require¬ 
ments  solution  from  each  constrained  cost  algorithm.  The  model  selects  the 
requirements  solution  associated  with  the  larger  value  of  fraction  flying 
program  achieved.  The  requirements  parts  list  for  the  selected  solution  is 
shown  in  the  output  report  (Figure  3-17)  following  this  one. 

CASE  =  PART  SUB  OOC  EX 
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Figure  3-16.  Constrained  Cost  Total  Requirements  Solution  Evaluation  Report 
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(7)  Constrained  Dollar  Total  Requirements  Parts  List  (Figure  3-17). 

This  output  is  only  printed  if  the  input  cost  limit  is  less  than  the  cost 
of  the  unconstrained  cost  solution.  Since  the  "buy"  implied  by  the  con¬ 
strained  cost  algorithm  often  only  approximates  (but  never  exceeds)  the 
input  cost  limit,  both  the  input  cost  limit  and  the  amount  used  in  the  solu¬ 
tion  are  given  in  the  table  header.  The  type  solution  is  also  given  in 
that  header  as  either  a  "cheapest  no-sub  parts/sustainability  solution" 
(denoting  an  algorithm  1  solution)  or  a  "sustainability  solution  for  cost 
through  N  days"  (denoting  an  algorithm  2  solution).  N  denotes  the  period 
of  flying  program  sustainability  reflected  by  that  solution.  As  noted  pre¬ 
viously,  the  constrained  cost  methodology  computes  two  solutions  using  two 
algorithms  and  chooses  the  one  yielding  the  higher  flying  hour  productivity 
in  terms  of  fraction  total  flying  program  achieved.  Only  the  chosen  solution 
is  printed  in  this  output  list.  Parts  are  listed  either  in  order  of  decreas¬ 
ing  amount  of  requirement  or  in  order  of  decreasing  part  unit  cost,  depending 
on  the  value  of  IORD  in  the  Scenario  Oata  Base  (Table  2-5).  Each  processed 
part  NSN  and  description  are  listed,  along  with  the  solution  amount  required, 
the  cost  of  that  amount  and  the  percent  of  total  cost  represented  by  that 
amount.  The  listed  solution  tends  heuristical ly  toward  the  maximally  produc¬ 
tive  (in  terms  of  supportable  program  flying  hours)  constrained  cost  parts 
mix  which  is  priced  at  the  input  cost  limit.  A  zero  initial  inventory  and 
use  of  the  input-specified  partial-substitution  policy  are  assumed. 
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Figure  3-17.  Constrained  Dollar  Total  Requirements  Parts  List 


(8)  Constrained  Dollar  Total  Requirements  Force  Capability  List 
(Figure  3-18).  The  output  shows,  under  the  specified  partial-sub  policy 
and  for  an  initial  spare  pool  stock  equal  to  the  previously  computed 
(Figure  3-17  above)  constrained  cost  total  stock  requirement: 

•  Expected  achievable  daily  and  average  aircraft  availability. 

•  The  daily  and  average  minimum  aircraft  availability  required  to 
meet  the  base  case  objective. 


_*•  .*•  .*•  , 
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•  Expected  daily  and  average  fraction  of  program  flying  hours 
f 1 own . 

•  Expected  daily  and  average  program  hours  flown  per  available 
aircraft  per  day. 

In  addition,  since  the  achieved  flying  hours  are  computed  by  means  of  a 
daily  iterative  convergence  process,  information  on  the  closeness  of  the 
overall  convergence  is  printed  in  the  header  TOTAL  FLY  HRS  CONVERGED  TO 
WITHIN  X.XX  PERCENT.  On  each  day,  each  iteration  produces  a  pair  of 
"achieved  flying  hour"  estimates,  an  initial  one  and  a  final  one.  After 
all  days  are  processed,  the  overall  convergence  closeness,  denoted  by  X.XX 
PERCENT,  is  expressed  as  the  sum  (over  all  days)  of  the  absolute  differences 
between  initial  and  final  estimates  divided  by  the  sum  of  the  final  daily 
estimates.  The  value  of  X.XX  is  determined  by  inputs  CONVF  and  LIMIT  in 
Record  Sets  1  and  4,  respectively,  of  the  Scenario  Input  Data  Base.  Close¬ 
ness  can  be  improved  by  reducing  the  input  value  of  CONVF  and/or  increasing 
the  input  value  of  LIMIT.  The  cost  limit  used  in  the  case  is  printed  in 
the  header  format. 
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Figure  3-18.  Constrained  Dollar  Total  Requirements 
Force  Capability  List 


c.  Residual  Requirements  Case  Results.  The  following  outputs  are  for 
the  case  with  initial  inventory  =  current  inventory.  Results  are  add-on  to 
current  inventory.  In  this  case,  initial  stocks  are  distributed  in  theater 
over  the  schedule  specified  in  the  Parts  Data  Base.  Results  for  residual 
requirements  are  generated  only  if  ISEL  =  1  or  2  in  the  Scenario  Data  Base. 
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(1)  Unconstrained  Dollar  Residual  Requirements  Total  Cost  List  (Figure 
3-19).  The  output  shows  the  total  cost  of  the  least-cost  residual  require¬ 
ments  unconstrained  cost  solution  (add-on  based  on  input  initial  inventory). 
The  format  is  virtually  identical  to  that  of  the  Unconstrained  Dollar  Total 
Requirements  Total  Cost  List  (Figure  3-11).  Add-on  costs  have  been  computed 
by  cumulating  the  product  of  part  unit  cost  and  total  add-on  units  (of  the 
part)  required.  As  in  all  requirements  cases,  the  partial-sub  policy  speci¬ 
fied  in  Record  Set  2  of  the  scenario  data  base  applies. 


CAS E=  PART  SUB  DOC  EX 
RESIDUAL! INIT  STKrCURR  STKI  COST  OF  RQHTS 
POLICY  TOT  COST 

PART  SUB  6300* 


Figure  3-19.  Unconstrained  Dollar  Residual  Requirements 

Total  Cost  List 


(2)  Unconstrained  Dollar  Residual  Requirements  Parts  List  (Figure 
3-20).  The  output  shows  the  composition  of  the  residual  unconstrained  cost 
requirements  solution  mix  (based  on  input  initial  inventory).  Format  is 
virtually  identical  to  that  of  the  Total  Requirements  Parts  List  (Figure 
3-12),  i.e.,  parts  are  listed  in  the  same  order  (by  decreasing  requirement 
amount).  Add-on  units  required,  cost  of  add-on  requirement,  and  associated 
percent  of  overall  requirement  are  listed  for  each  part. 


CASE:  PART  SUB  00C  EX 

RESIDUAL  UNIT  STKSCURR  STKI  STK  ROUTS 


part  nr 


? 

3  1 

A  3 


PART 


PART  9 
PART  I 
PART  A 
PART  3 


PART  2  GUN 
PART  I  GUN 
PART  A  GUN 
PART  3  GUN 


RQNNT  COST  (COST 


•0  0.  *00 


Figure  3-20.  Unconstrained  Dollar  Residual  Renwireaente  Parte  Met 
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(3)  Selected  Items  Cumulative  Residual  Requirements  List  (Figure  3-21). 

This  output  consists  of  residual  unconstrained  cost  requirements  for  each 
of  up  to  100  selected  part  types  for  a  truncated  scenario  of  length  N  days, 
where  N  =  1,  2,  ...  through  the  last  day  of  the  Base  Case  Scenario.  It  is 
an  exact  analogue  of  the  Selected  Items  Cumulative  Total  Requirement  List 
(Figure  3-13)  except  that  the  residual  requirements  are  treated. 


(lift  FMV  KM  ON  (I 

am  im-or  ••mviiHii 

ftiHsam* 

IHVO  ICIMKI 

TMtt  ftlVCI 

MV 

out  M  | 

MIT  M  t 

MIT 

M  • 

MIT 

Ml  0 

MIT  M 

0 

OlOT  1 

Oil!  1  Mi 

MV 

M.T  I  US’  * 

MV 

MV 

MV 

ftftV 

!  J 

ft  M.S 

}  :l 

1  U:i 

i 

l 

i 

i 

1 

.1 

:! 

!  ii 

Figure  3-21.  Selected  Items  Cumulative  Residual  Requirements  List 


(4)  Residual  Requirement  Cumulative  Cost  List  (Figure  3-22).  Output 
consists  of  total  costs  (all  parts)  of  the  residual  unconstrained  cost 
requirements  solution  (add-on  based  on  initial  inventory)  for  each  policy 
applied  in  a  truncated  scenario  of  N  days,  N  =  1,  2,  ...  through  the  last 
day  of  the  base  scenario.  It  is  an  analogue  of  the  Total  Requirement  Cumu¬ 
lative  Cost  List  (Figure  3-14).  These  are  add-on  costs.  Initial  inventory 
is  not  costed  here,  but  is  treated  as  a  "sunk"  asset.  The  costs  on  the 
last  line  (day)  of  the  output  list  should  be  the  same  as  those  in  the  Uncon¬ 
strained  Dollar  Residual  Requirements  Cost  List  (Figure  3-19,  above).  Another 
interpretation  of  this  output  is  that  it  gives,  for  each  policy,  the  expected 
cost  for  residual  (add-on)  requirements  required  to  sustain  the  flying 
hour/availability  objective  through  any  specified  day  of  the  scenario.  After 
the  list,  a  summary  of  the  cost  limit  approximation  used  in  constrained 
cost  algorithm  2  for  this  case  is  also  given. 
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Figure  3-22.  Residual  Requirement  Cumulative  Cost  List 


(5)  Unconstrained  Dollar  Residual  Requirements  Force  Capability  List 
(Figure  3-23).  The  output  is  analogous  to  the  comparable  list  for  total 
requirements  (Figure  3-15),  i.e.,  it  shows,  for  each  day,  expected  aircraft 
availability,  required  availability  (and  source),  and  flying  hours  per  air¬ 
craft  per  day,  assuming  that  the  computed  residual  unconstrained  cost  require 
ment  (Figure  3-20)  is  added  to  the  stocks  in  the  theater  war  reserve. 
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(6)  Constrained  Dollar  Residual  Requirements  Solution  Evaluation  Report 
(Figure  3-24).  This  output  is  exactly  analogous  to  the  Total  Requirements 
Solution  Evaluation  Report  (Figure  3-16)  except  that  residual  (add-on  to 
current  inventory)  requirements  are  treated  here. 
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Figure  3-24.  Constrained  Dollar  Residual  Requirements 
Solution  Evaluation  Report 


(7)  Constrained  Dollar  Residual  Requirements  Parts  List  (Figure  3-25). 

This  list  is  exactly  analogous  to  the  Constrained  Dollar  Total  Requirements 
List  (Figure  3-17).  It  is  only  printed  if  the  input  cost  limit  for  residual 
requirements  is  less  than  the  cost  of  the  corresponding  unconstrained  cost 
solution.  Each  processed  part  NSN  and  part  description  are  listed,  along 
with  the  solution  amount  required,  the  cost  of  that  amount,  and  the  percent 
of  total  cost  represented  by  that  amount. 
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Figure  3-25.  Constrained  Dollar  Residual  Requirements  Parts  List 


(8)  Constrained  Dollar  Residual  Requirements  Force  Capability  List 
(Figure  3-26).  The  output  shows  the  same  information  as  in  Figure  3-18, 
above,  but  for  an  initial  spare  pool  stock  equal  to  the  sum  of  the  previously 
computed  (Figure  3-25)  constrained  cost  residual  stock  requirement  and  the 
original  initial  stock.  The  computed  requirement  is  assumed  to  be  added  to 
the  theater  war  reserve.  Information  on  the  closeness  of  convergence  of 
achieved  flying  hours  is  printed  in  the  table  header. 
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Figure  3-26.  Constrained  Dollar  Residual  Requirements 
Force  Capability  List 


d.  Current  Inventory  Capability  Assessment  Results  (Figure  3-27).  After 
all  requirements  results  are  printed.  Extended  PARCOM  prints  capability 
assessment  results  for  current  inventory  under  the  partial-substitution 
policy  specified  for  requirements  cases  as  well  as  optional  results  under  a 
variety  of  additional  user-specified  partial-substitution  policies.  Outputs 
are  as  shown  in  the  paragraphs  following. 
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Figure  3-27.  Current  Inventory  Capability  Assessment  Under  Policy  1 


(1)  Current  Inventory  Capability  Assessment  Under  Policy  1  (Base). 

The  output  consists  of  the  daily  and  average  achieved  availability,  achieved 
fraction  of  flying  program  and  achieved  program  flying  hours  per  aircraft 
per  day  for  current  inventory  under  the  partial-substitution  policy  used  in 
the  requirements  cases.  That  policy  is  specified  in  Record  Set  2  of  the 
Scenario  Data  Base.  The  format  and  general  content  of  the  list  is  the  same 
as  in  the  Constrained  Dollar  Force  Capability  Lists  (Figures  3-18  and  3-26) 
for  Requirements  Cases. 

(2)  Full-sub  Parts  List  for  Policy  2  (Figure  3-28).  This  list  displays, 
in  order  of  input,  data  for  those  parts  in  the  full-sub  parts  set  used  in 
Policy  2.  Policy  2  refers  to  the  first  partial-substitution  policy  defined 

by  the  user  in  Record  Set  11  of  the  Scenario  Data  Base.  This  output  is 
printed  only  if  a  positive  value  for  I0PT2  is  set  in  Record  Set  5  of  the 
Scenario  Data  Base. 
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(3)  No-sub  Parts  List  for  Policy  2  (Figure  3-29).  This  list  displays, 
in  order  of  input,  data  for  those  parts  in  the  no-sub  parts  set  used  in 
Policy  2.  (Policy  2  is  described  above.)  This  output  is  printed  only  if  a 
positive  value  for  I0PT3  is  set  in  Record  Set  5  of  the  Scenario  Data  Base. 
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Figure  3-29.  No-sub  Parts  List  for  Policy  2 


(4)  Current  Inventory  Capability  Assessment  Under  Policy  2  (Figure 
3-30).  This  output  shows  daily  and  average  achieved  availability,  achieved 
fraction  of  flying  program,  and  achieved  program  flying  hours  per  aircraft 
per  day  for  current  inventory  under  the  partial-substitution  Policy  2  de¬ 
scribed  previously. 
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Figure  3-30.  Current  Inventory  Capability  Assessment  Under  Policy  2 


5-85 


DTIC 


